# Configuration as Secrets

When running workloads in kubernetes most people will have a mechanism for
handling secrets. Some parts of the rig configuration should also be considered
confidential. Rig has two primary ways of loading configuration, either through
a config file or through environment variables.

The helm chart both supports rendering a Secret containing a config file, but
it also supports rendering a Secret used as environment variables. However most
people will prefer storing secrets outside of helm, which means that no secret
information should be passed to helm through values. Instead you might be using
[sealed-secret](https://github.com/bitnami-labs/sealed-secrets) or
[external-secrets](https://external-secrets.io) as a layer inbetween your
secrets and the kubernetes `Secret` resource.

This article will be a brief explaination of how to use secrets provided by a
third party in conjunction with the helm chart.

## Environment variables or configfiles

Some people like using configfiles more, while others enjoy environment
variables. The helm chart supports both.

The first thing to do is to set the helm value which points to the third party
secret.

```yaml title="Helm values - Operator"
secretName: "my-rig-config"
useEnvForSecrets: false
```

Here you might notice that `useEnvForSecrets` is set to false (this is the
default). This means that we will expect the secret "my-rig-config" to have a
key called config.yaml, which holds a configuration file with the secret parts
of our configuration. By default `secretName` is not set, which will make helm
generate the secrets we need. By setting it we tell helm to forget about
creating secrets and instead use an existing one.

If you would prefer to use environment variables for the secret parts of the
configuration, you would instead set it to true.

```yaml title="Helm values - Operator"
secretName: "my-rig-config"
useEnvForSecrets: true
```

In this case we expect "my-rig-config" to hold environment variables for
configuring rig.
